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Abstract 


An 802.11 D1 Letter Ballot comment by Ed Geiger on Section 5.2 (postponed for later discussion at 
the March, 1995 meeting, see document 95/067) identifies a potential intellectual property issue over 
the RTS/CTS mechanism proposed for use in the 802.11 MAC. This submission discusses the scope 
of the subject patent, and states the reasons which the submitter believes that no conflict exists. 


Desired Outcome 


Resolution or this letter ballot comment, which calls for removal of RTS/CTS mechanism 
from the standard, as ‘hot accepted” due to non-relevance of the cited intellectual property to 
the 802.11 MAC as currently defined. 


Disclaimer 


The author of this submission is not an attorney, and this document is not a legal opinion 
concerning the scope of the patented subject matter nor the relevance of this patent to any 
proposal under consideration by the P802.11 working group. The statements herein regarding 
the scope of the patent are technical opinions from an individual who is familiar with the 
patented subject matter through the use of Apple Computer equipment and Apple’s published 
documentation, and is familiar with technical interpretation of networking patents from other 
work as a technical expert on several patent infringement cases. 
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Background 


In 1993, Apple Computer identified U.S. patents 4,661,902 (‘the ‘902 patent”) and 4,689,786 (‘the 
‘786 patent) as potentially relevant to proposals before P802.11. Both of these patents were filed on 
March 21, 1985, based on the same specification. This specification describes the physical and link 
layer implementation of Apple’s LocalTalk™ network. The abstracts mention the use of a ‘three step 
handshake, wherein the sending agent transmits an “RTS” signal and within a predetermined time 
must receive a “CTS” signal from the receiving agent.” 


In the D1 letter ballot, Ed Geiger made the comment “Remove the usage of RTS/CTS in the 
standard” with the stated reason that “Apple Computer supplied the committee with a statement 
which indicated that the RTS/CTS reservation mechanism may infringe upon a specific patent. Apple 
has never submitted any licensing statement regarding the use of any of their patented technology 
which might appear in the Standard” [doc 95/18-5/1R1, March, 1995, p. 33]. 


Resolution of this comment was ‘postponed to later discussion.” This submission provides a 
proposed basis upon which to resolve this comment. 


The ‘786 Patent 


U.S. Patent 4,689,786 is entitled “Local Area Network with Self Assigned Address Method.” While 
both the abstract and specification of this patent mention the use of RTS/CTS, the claims do not — 
so it can be assumed that the letter ballot comment, which did not indicate a specific patent, is not 
referring to ‘786. An additional basis for non-relevance is that, of this patent’s 19 claims, only 2 are 
independent claims, and those each begin by requiring an apparatus or method “.. for assigning a 
unique address to a data processing device ...” —- which is not done by any IEEE 802 LAN. 


The ‘902 Patent 


U.S. Patent 4,661.902 is entitled “Local Area Network with Carrier Sense Collision Avoidance.” 
Dependent claims under two of the three independent claims of this patent refer to the use of RTS 
and CTS frames, wherein the absence of the later in a defined IFG time is used to generate a 
‘collision assumption” or a ‘collision signal.” Read in isolation, these claims appear broadly to cover 
the use of the RTS/CTS mechanism on a LAN. However, by 1985, when this patent application was 
filed, the various mechanisms mentioned in the claims were in widespread use on other networks. 
Therefore, for these claims to be valid (rather than being invalid due to “obviousness” or “prior use”) 
they must be interpreted quite narrowly. This narrow interpretation does not cover the 802.11 MAC 
protocol, because 802.11’s use of RTS/CTS differs in several, distinct areas from LocalTalk’s use of 
RTS/CTS. 


Certainly the ‘902 patent is not a fundamental patent: 
e CSMA dates back to the Aloha network in the early 1970s; 


e collision avoidance was used on Network Systems’ HyperChannel™ & HyperBus™, 
developed in the mid—1970s, as well as on several other networks (mostly Aloha derivatives) 
operational well before 1984; 


e RTS and CTS packets (rather than discrete, out-of-band RTS & CTS signals) were used in 
wide area networks at least as far back as some of the first airline reservation systems in the 
mid—1960s, and on local area networks since the introduction of ARCNET® in 1977; and 
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e synchronization pulses at the beginning of frames are used in ARCNET (as well as many other 
pre-1984 LANs), and the use of missing clock transitions to render the synchronization signal 
unique dates back, at least, to the early 1970s with the IBM 3274 Control Unit/Terminal 
signaling scheme. 


Of greatest significance to possible applicability to the 802.11 MAC are the instances of prior art 
using RTS/CTS frames. 


Prior Use of RTS/CTS Frames 


The ‘902 patent claims an RTS frame ‘including at least one synchronization flag byte having a 
predefined bit sequences and a type field containing an RTS byte” (claims 7 & 30), and a CTS frame 
‘including at least one synchronization flag byte and a type field containing a CTS byte” (claims 9 & 
32). An almost identical mechanism, with different nomenclature, is used by ARCNET. From a prior 
art standpoint, ARCNET constitutes public disclosure of RTS/CTS, not later than 1983. Datapoint 
Corp. never filed any patent applications on ARCNET. General information on the ARCNET 
protocol appeared in the descriptive literature distributed at the time of original product introduction 
(1977, this author received such information at the Datapoint booth of the 1977 National Computer 
Conference). Some aspects of the ARCNET protocol remained Datapoint trade secrets until 1981, 
when Standard Microsystems Corp. (SMC) was licensed to sell the ARCNET controller chip as a 
standard product. The ARCNET MAC (and PHY) protocols were described in the data sheets and 
application notes on SMC’s ‘COM9026,” some of which were published in 1981 and 1982. An 
detailed description of the ARCNET MAC appeared in the ARCNET Designer ’s Handbook, the first 
edition of which was published by Datapoint in 1983 (publication #61610). This handbook was 
widely distributed, initially at no charge, later for a nominal fee. 


ARCNET uses a 4-stage frame exchange sequence for directed data packets: (1) The “RTS” frame, 

which is called a ‘Free Buffer Equiry” (FBE), and is comprised of an Alert Burst (establishes 

synchronization), an ENQ frame type byte, and a destination address. (2) The “CTS” frame, which is 

called an “Acknowledgment” (ACK), and is comprised of an Alert Burst and an ACK frame type 

byte. (3) The data packet frame. (4) An Acknowledgment to the data frame (only if received without 
errors). The ACK frames must be received within 74.6 microseconds after the FBE or data packet 
frames, or a response timeout occurs. Broadcast packets are sent without FBE/ACK and are not 
acknowledged by the recipients. 


The ARCNET FBE/ACK mechanism is functionally equivalent to the LocalTalk RTS/CTS 
mechanism, but was in commercial use 8 years earlier. There is an operational difference because 
ARCNET uses token passing to control the right to transmit, so the results of the RTS/CTS exchange 
are used for flow control and detection of absent/inactive destination stations (thereby conserving 
medium bandwidth for deliverable data frames). On LocalTalk, the lack of a CTS may occur because 
of a data error on the medium, an absent/inactive station, or a collision. The relative frequency of 
collisions versus medium errors on the preferred LocalTalk medium leads to a presumption of 
collision when a CTS is not received. 


The use of RTS/CTS frame exchanges prior to 1984 was not limited to ARCNET (a token bus LAN), 
nor to token-based networks. Another widely known local network that used such frame exchange 
sequences was the Cambridge Ring (a slotted ring LAN), under its Single Shot Protocol and its Byte 
Stream Protocol. Because of the Cambridge Ring’s fine-grain interleaving of “minipackets,” its 

RTS-equivalent mechanism was needed to detect ‘tollisions” as well as for flow control. A 

“collision” on a minipacket network occurs when the addressed recipient is unable to receive the data 
frame because the assembly of minipackets of a frame from another sender is currently in progress. 
One of many publications describing the Cambridge Ring is the monograph The Cambridge 
Distributed Computing System, R.M. Needham & A. J. Herbert, Addison-Wesley, 1982 (ISBN 0- 
210-14092-6). 
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Differences Between the RTS/CTS Mechanisms in 802.11 and the ‘902 Patent 


Because the use of RTS/CTS frame exchanges on LANs, for flow control, medium availability 
determination, medium usage optimization, and collision detection, pre-dated the development of 
LocalTalk and the filing of the “902 patent by many years, the scope of the ‘902 claims related to 
RTS/CTS is much narrower than an isolated reading might indicate. The embodiment described in 
the patent specification is quite different than that defined for the 802.11 MAC: 


e The ‘902 patent describes a protocol where RTS frames are used before broadcasts 
(without eliciting a CTS response) as well as before directed data frames. 802.11, like 
ARCNET, only sends RTS frames before directed data frames. 


e The ‘902 patent describes a 3-stage handshake (RTS-CTS—Data), whereas 802.11, like 
ARCNET, uses a 4—stage handshake (RTS-CTS—Data—ACK). 


e Despite the term ‘collision avoidance” in its title, the network described in the ‘902 patent 
does not actually have a collision avoidance mechanism. Instead, failure to receive a 
timely CTS response is used as a collision detection mechanism, in lieu of PHY—layer 
collision detection as is used by 802.3 (Ethernet). The ‘collision avoidance” of the ‘902 
patent is actually avoidance of collisions involving the data frames. This is confirmed in 
the text of the specification, which states “.. the purpose of the three step handshake 
protocol described above is to avoid collisions by restricting the periods in which 
collisions are highly likely (typically during the RTS and CTS frame exchanges) ...” 
(column 8, lines 49-53). The 802.11 protocol includes an actual collision avoidance 
mechanism (the NAV’s ‘Virtual carrier sense’), which operates in parallel with the 
physical carrier sense and RTS/CTS handshake. Basing backoff and deferral decisions, 
prior to the transmission of the RTS, on information obtained from MAC fields in 
preceding frames (including those addressed to other stations and even those from other 
BSSes) is distinctly different from the ‘902 protocol (as well as from most other collision 
avoidance protocols). 


e The 802.11 protocol, like the Cambridge Ring, uses the RTS/CTS exchange to establish 
the instantaneous presence of the physical link — a very important function when trying to 
tun a LAN over wireless media, but one that is not mentioned in the ‘902 specification. 


e The ‘902 protocol uses an isolated pulse, followed by missing clocks, to establish 
synchronization (largely due to idiosyncrasies of the 8530 SCC used as the LocalTalk 
controller), and a unique abort sequence as an end-of-frame delimiter. 802.11 uses a 
unique word, sent using the normal modulation technique of the active PHY as a starting 
delimiter, and determines end-of-frame using a CRC-protected length indicator in the 
frame header, rather than an ending delimiter. Reliance on positive detection of a unique 
ending delimiter is likely to yield poor operational results with some wireless media, 
especially RF media in ISM bands. 


Conclusion 


The ‘786 patent is not relevant to 802.11 because of its requirement for dynamically-assigned 
network addresses. 


The ‘902 patent is not relevant to 802.11 because its claims must be construed quite narrowly due to 
prior art networks which use RTS/CTS packet exchange mechanisms, and there are significant 
functional and operational differences (some of which are directly relevant to the successful operation 
over a wireless medium) between 802.11’s RTS/CTS mechanism and LocalTalk’s RTS/CTS 
mechanism. 
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